United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
United States Patent and Trademark Office 
Address: COMMISSIONER FOR PATENTS 
P.O. Box 1450 

Alexandria, Virginia 22313-1450 
www.uspto.gov 



APPLICATION NO. 



FILING DATE 



FIRST NAMED INVENTOR 



ATTORNEY DOCKET NO. CONFIRMATION NO. 



09/766,943 



01/22/2001 



7590 



08/22/2006 



25537 

VERIZON 

PATENT MANAGEMENT GROUP 
1515 N. COURTHOUSE ROAD 
SUITE 500 

ARLINGTON, VA 22201-2909 



John K. Gallant 



R1C000016 



3388 



EXAMINER 



MOORE, IAN N 



ART UNIT 



PAPER NUMBER 



2616 

DATE MAILED: 08/22/2006 



Please find below and/or attached an Office communication concerning this application or proceeding. 



PTO-90C (Rev. 10/03) 



Office Action Summary 


Application No. 

09/766,943 


Applicant(s) 
GALLANT ET AL 


examiner 

Ian N. Moore 


Art Unit 

2616 





- The MAILING DATE of this communication appears on the cover sheet with the correspondence address ~ 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .1 36(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S. C. § 1 33). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1)^ Responsive to communication(s) filed on 12 June 2006 . 
2a)D This action is FINAL. 2b)El This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 1 1 , 453 O.G. 213. 

Disposition of Claims 

4) ^ Claim(s) 1-50 and 54-81 is/are pending in the application. 

4a) Of the above claim(s) 66-81 is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) K! Claim(s) 1-50.54-65 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) D The specification is objected to by the Examiner. 

10) D The drawing(s) filed on is/are: a)D accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

1 1) D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12) D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)D All b)D Some * c)D None of: 

1 .□ Certified copies of the priority documents have been received. 

2- D Certified copies of the priority documents have been received in Application No. . 

3- D Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attach ment(s) 

1) 03 Notice of References Cited (PTO-892) 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) 

3) D Information Disclosure Statement(s) (PTO-1449 or PTO/SB/08) 

Paper No(s)/Mail Date . 



4) □ Interview Summary (PTO-413) 

Paper No(s)/Mail Date. . 

5) D Notice of Informal Patent Application (PTO-152) 

6) □ Other: . 



U.S. Patent and Trademark Office 
PTOL-326 (Rev. 7-05) 



Office Action Summary 



Part of Paper No./Mail Date 20060628 



Application/Control Number: 09/766,943 Page 2 

Art Unit: 2616 

DETAILED ACTION 
Claim Objections 

1 . Claim 60 is objected to because of the following informalities: 

Claim 60 recites, "IBR" in line 2. For consistency, it should be change to "VBR" for 
variable bit-rate. 

Appropriate correction is required. 



Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 

3. Claims 1-3,5,1 1,12,14-16,18, and 31 are rejected under 35 U.S.C. 1 02(e) as being 
anticipated by Buyukkoc (US 6.463.062). 

Regarding claim 1, Buyukkoc discloses an intelligent policy server (see FIG. 7-9, 
central Routing Status Database server, RDS) method in an synchronous Transfer Mode (ATM) 
network (see FIG. 7-9, ATM network; see col. 19, line 55-60) having an ingress switch (see FIG. 
9, ATM switch 922) and an egress switch (see FIG. 9, ATM switch 924), wherein said ingress 
switch serves an ingress device (see FIG. 9, switch 912) operated by a calling party (see FIG. 9, 
User 902) and said egress switch serves an egress device (see FIG. 9, Switch 914) operated by a 



Application/Control Number: 09/766,943 Page 3 

Art Unit: 2616 

called party (see FIG. 9, user 904); see col. 19, line 61 to col. 20, line 24), comprising the steps 
of: 

receiving, in said ingress switch, a signaling message from said ingress device (see FIG. 
9, step 810, edge node receive a new call; see col. 19, line 19-26; also see FIG. 10, step 
1005,1010,1015,1020,1025,1030; see col. 20, line 50-67); 

providing said signaling message to a signaling intercept processor (see FIG. 7, a link 750 
to Regional RSD server, RRSD, 740; see col. 13, line 22-46) associated with said ingress switch 
(see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 19, line 25-30; edge node send a call 
query/message to RSD; also see FIG. 10, step 1035); 

propagating said signaling message to a policy server (see FIG. 7, a link 770 to central 
RDS server 730, i.e., Signaling Control Point, SCP), said policy server including at least one 
policy profile associated with a plurality of policy features (see col. 14, line 9 to col. 15, line 50; 
see col. 10, line 10-20; see col. 1 1, line 1-16; see col. 13, line 1-6, 29-67; RSD contents consists 
connection rules/policy such as connectively information, threshold, quality of service, capacity, 
and/or status of loading/congestion), each policy profile of the at least one policy profile being 
associated with a subscriber (see col. 14, line 35-64; a quality of service rule/policy is one of the 
rule/policy associated with a call, where a call is associated with a user/subscriber); 

determining in said policy server, based at least in part on said signaling message, if a 
particular policy feature of the plurality of policy features is to be invoked (see FIG. 8, step 840; 
see FIG. 10, steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; Tables VII-IX; decide 
how to route the call in accordance RSD contents by determining and triggering/invoking a 
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particular/specific quality-of-service rule/policy of connection rules/policies for received call's 
priority of traffic); 

if so, determining whether a policy condition associated with said particular policy 
feature is satisfied with respect to said signaling message (see FIG. 8, step 840; see FIG. 10, 
steps 1035,1040; see col 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, 
line 19-30; determines/decides whether the load/congestion/priority/bandwidth/routes/quality-of- 
service conditions are met/fulfilled); 

establishing a connection path between said ingress switch and said egress switch based 
on said determination that said policy condition is satisfied by said signaling message (see FIG. 
8, step 850, 860, 870; see FIG. 10, steps 1045,1050,1055; see col. 14, line 1-65; see col. 19, line 
35-50; see col. 21, line 40-50; setting/establishing the call when 
load/congestion/priority/bandwidth/routes conditions are met/fulfilled). 

Regarding claim 14, Buyukkoc discloses an Asynchronous Transfer Mode (ATM) 
network (see FIG. 7-9, ATM network; see col. 19, line 55-60) for effectuating intelligent policy 
features with respect to a call to be established between two parties (see FIG. 9, a connection 
user 904 and 902) via a virtual channel connection (see col. 20, line 1-45; a virtual circuit); see 
col. 19, line 61 to col. 20, line 24, comprising: 

an ATM switch (see FIG. 9, ATM switch 922) serving a customer premises equipment 
(CPE) operated by a party with respect to said call (see FIG. 9, CPE User 902 connects TDM 
switch 912; see col. 19, line 64 to col. 20, line 25); 

a signaling intercept processor (see FIG. 7, Regional RSD server, RRSD, 740; see col. 
13, line 22-46) associated with said ATM switch for intercepting a signaling message relative to 
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said call (see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 19, line 25-30; edge node 
send a call query/message to RSD; also see FIG. 10, step 1035); 

a policy server (see FIG. 7, central RDS server 730, i.e., Signaling Control Point, SCP) 
associated with said signaling intercept processor, said policy server including at least one policy 
profile having a plurality of policy features (see col. 14, line 9 to col. 15, line 50; see col. 10, line 
10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD contents consists connection 
rules/policy such as connectively information, threshold, quality of service, capacity, and/or 
status of loading/congestion), the at least one policy being associated with a subscriber (see col. 
14, line 35-64; a quality of service rule/policy is one of the rule/policy associated with a call, 
where a call is associated with a user/subscriber), wherein said policy server operates to 
effectuate a particular policy feature of the plurality of policy feature with respect to said call 
when triggered by said signaling message received from said signaling intercept processor (see 
FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; see 
col. 19, line 25-40; see col. 21, line 19-30; RSD determines/decides whether a particular/specific 
quality-of-service rule/policy of the load/congestion/priority/bandwidth/route/quality-of-service 
condition of a new call/connection is met/fulfilled when receiving setup message from a user (via 
RRSD)). 

Regarding claims 2, 15, Buyukkoc discloses wherein said signaling message comprises 
a Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claims 3,5,16,18, Buyukkoc discloses wherein said signaling message 
comprises an Add Party or setup message (see FIG. 8, steps 820,830; a message which contains a 
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new call requesting for a route is the SETUP/adding party message in ATM signaling/SS7; see 
col. 19, line 19-31; see col. 20, line 46-52; see col. 20 5 line 39-45; see col. 21, line 19-25). 

Regarding claim 11, Buyukkoc discloses an aggregated bandwidth limit feature (see col. 

17, line 30-40; see col. 13, line 45-47; total bandwidth). 

Regarding claim 12, Buyukkoc discloses a service class selection feature (see col. 10, 
line 50-55; see col. 18, line 26-45; class-of-service). 

Regarding claim 31, Buyukkoc discloses a service class selection feature for specifying 
a service class with respect to a network port used by said party (see col. 10, line 50-55; see col. 

18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of-service for a 
port/link/trunk/circuit used by the call). 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. Claim 4 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Noake (US006751222B1). 

Regarding claims 4 and 17, Buyukkoc does not explicitly disclose a release message. 
However, a release message is well know in the ATM signaling/SS7 in order to disconnect the 
call. In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
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time the invention was made to provide a release message, as taught by Noake in the system of 
Buyukkoc, so that it would make effective use of a band and the respective apparatus by 
transmitting connection information, and by sending/receiving a release message it will notify to 
stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; col. 8, line 
19-24. 

6. Claims 6-9,19-21,23, and 25 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Buyukkoc in view of Christie f 656 (US006690656B1). 

Regarding claims 6, 8 and 9, Buyukkoc does not explicitly disclose a source address 
validation/screening and a destination address screening. However, a source address 
validation/screening is well known in the ATM signaling/SS7. In particular, Christie'656 teaches 
a source address validation/screening and a destination address screening (see FIG. 7; see col. 7, 
line 9-19, 35-45; checking/validating caller number in ANI and verifying a dial number). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to validate/verify the caller number and dial number, as taught by 
Christie'656 in the system of Buyukkoc, so that it would can validate the calls and generate a 
billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 19, Buyukkoc discloses accessing said ATM network through a 
particular network port associated with said CPE (see FIG. 9, accessing Switch 922 through the 
trunk/port 932; see col. 20, line 1-10). 

Buyukkoc does not explicitly disclose a source address validation for ensuring that said 
party is an authorized party for accessing the network. 



Application/Control Number: 09/766,943 Page 8 

Art Unit: 2616 

However, a source address validation for ensuring that said party is an authorized party 
for accessing the network is well known in the art of signaling in order to established the call. In 
particular, Christie'656 teaches a source address validation for ensuring that said party is an 
authorized party for accessing the ATM network (see FIG. 7; see col. 7, line 9-19, 35-45; 
checking/validating caller number in ANI for verification for accessing ATM network). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to validate/verify the caller number to access the ATM network, as taught by 
Christie'656 in the system of Buyukkoc, so that it would can validate the calls and generate a 
billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 20, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port between customer and the network). Christie'656 also discloses a 
Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 21, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

Regarding claim 23, Buyukkoc does not explicitly disclose a destination address 
screening for defining a plurality of address to which said party can effectuate said call. 
However, a destination address/number validation/screening for defining a plurality of 
address/numbers to which said party can effectuate said call is well known in the signaling with 
SCP. In particular, Christie'656 teaches a destination address screening for defining a plurality of 
address to which said party can effectuate said call (see FIG. 7; see col. 7, line 9-19, 35-45; see 
col. 15, line 40-60; see col. 2, line 1-15; verifying a dial number from the list of numbers where 
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the call needs to be connected). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to validate/verify dial number from the list of 
number to establish the call, as taught by Christie f 656 in the system of Buyukkoc, so that it 
would can validate the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 
7, line 39-45. 

Regarding claims 25, Buyukkoc does not explicitly disclose a source address screening 
for defining a plurality of address from which said call can be initiated to said party. However, a 
source address/number validation/screening for defining a plurality of address from which said 
call can be initiated to said party is well known in the signaling with SCP. In particular, 
Christie'656 teaches a source address screening for defining plurality of address from which said 
call can be initiated to said party (see FIG. 7; see col. 7, line 9-19, 35-45; see col. 15, line 40-60; 
see col. 2, line 1-15; verifying a caller number, from the list of numbers, to initiate a 
call/connection). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to validate/verify caller number from the list of number to 
initiate a call, as taught by Christie'656 in the system of Buyukkoc, so that it would can validate 
the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

7. Claims 7 and 22 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Farris (US006 154445 A). 

Regarding claim 7, Buyukkoc does not explicitly disclose a maximum call attempt rate 
limit. However, having a maximum call attempt rate limit/threshold is well known in the 
signaling/SS7. In particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1- 
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12; see col. 11, line 5-17; acceptable/maximum specified rate of call attempts). Therefore, it 
would have been obvious to one having ordinary skill in the art at the time the invention was 
made to provide acceptable/maximum specified rate of call attempts, as taught by Farris in the 
system of Buyukkoc, so that it would can detect the predetermined events and/or imminence of 
predetermined events, and then blocking or controlling those events from their incipiency; see 
Farris col. 14, line 1-6. 

Regarding claim 22, Buyukkoc discloses the number of setup messages as described 
above in claim 18. 

Buyukkoc does not explicitly disclose a maximum call attempt rate limit for monitoring 
the number of messages received from said party over a predetermined period of time. However, 
having a maximum call attempt rate limit for monitoring the number of messages received from 
said party over a predetermined period of time is well known in the art of signaling and network 
management. In particular, Farris teaches a maximum call attempt rate limit for monitoring the 
number of setup messages received from said party over a predetermined period of time (see col. 
14, line 1-12; see col. 11, line 5-56; acceptable/maximum specified rate of call attempts for 
monitoring and determining the number of setup/ISUP messages from calling party per time 
period). Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide acceptable/maximum specified rate of call attempts and 
monitoring process, as taught by Farris in the system of Buyukkoc, for the same motivation as 
stated above in claim 7. 
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8. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of VanDervort (US005761 191 A), or Horn (US005276676A). 

Regarding claim 10, Buyukkoc discloses a policy feature comprises a maximum size 
limit feature (see col. 14, line 15-65; acceptable/maximum load/size/bandwidth before the call 
are blocked). 

Buyukkoc does not explicitly disclose burst. However, ATM network having a 
rule/policy/policing attribute burst size threshold/limiting for ATM flow control is well known in 
the art. In particular, VanDervort teaches a maximum burst size limit/threshold feature (see col. 
6, line 8-11; limited/maximum burst size limit/threshold of user cell transmission for policing). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to provide limited/maximum burst size, as taught by VanDervort in the 
system of Buyukkoc, so that it would control the flow of traffic and maximize the utilization of 
network resources; see VanDervort col. 6, line 1-3. 

Buyukkoc does not explicitly disclose burst. In particular, Horn teaches a maximum burst 
size limit/threshold feature (see col. 2, line 29-30; maximum burst length is limited by 
threshold). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide maximum burst length threshold, as taught by Horn in 
the system of Buyukkoc, so that it would avoid overflow problem due to long bursts; see Horn 
col. l,line 25-34. 

9. Claims 13 and 38 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Basso (US006633539B1). 
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Regarding claim 13, Buyukkoc discloses a policy feature comprises a maximum call 
limit feature (see col. 14, line 15-65; acceptable/maximum call load/limit/bandwidth). 

Buyukkoc does not explicitly disclose concurrent. However, ATM network having a 
maximum concurrent call limit/threshed for call admission control (C AC) is well known in the 
art. In particular, Basso teaches a maximum concurrent call limit feature (see col. 4, line 25-35; 
maximum allowed/limit number of concurrent connection/call). Therefore, it would have been 
obvious to one having ordinary skill in the art at the time the invention was made to provide 
maximum concurrent connection, as taught by Basso in the system of Buyukkoc, so that it would 
control concurrent connections/calls to provide efficient protection against signaling congestion; 
see Basso col. 2, line 35-45. 

Regarding claim 38, Buyukkoc discloses a policy feature comprise a maximum call 
limit feature for specifying the total number of calls allowed concurrently with respect to a 
network port used by said party (see col. 14, line 10 to col. 15, line 50; see FIG. 9, trunk/port 
932; see col. 20, line 1-10; acceptable/allowable total number of calls threshold/limit for a 
trunk/port). 

Buyukkoc does not explicitly disclose concurrent. However, ATM network having a 
maximum concurrent call limit/threshed for call admission control (CAC) is well known in the 
art. In particular, Basso teaches a maximum concurrent call limit feature (see col. 4, line 25-35; 
maximum allowed/limit number of concurrent connection/call). Therefore, it would have been 
obvious to one having ordinary skill in the art at the time the invention was made to provide 
maximum concurrent connection, as taught by Basso in the system of Buyukkoc, so that it would 
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control concurrent connections/calls to provide efficient protection against signaling congestion; 
see Basso col. 2, line 35-45. 

10. Claim 24 and 26 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Christie'656, as set forth above in claim 14, and further in view of Gai 
(US006 167445 A). 

Regarding claim 24, the combined of Buyukkoc and Christie'656 discloses destination 
address screening feature is established for a subscriber to which said party belongs as set forth 
above in claim 23. 

Neither Buyukkoc nor Gai explicitly discloses a group of subscribers. However, Gai 
teaches a policy server (see FIG. 4, policy server 322) comprising the particular policy feature 
(see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device-specific 
filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a destination 
screening feature for a group of subscribers to which the party belongs (see col. 14, line 1-15, 56 
to col. 15, line 55; applying destination addressing policy rule to a group of users (see FIG. 7A, 
marking users, admin users, executive users, etc.) where a specific user (see FIG. 7A, John Doe) 
belongs; see col. see col. 14, line 10-18). Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to provide a destination screening 
feature for a group of subscribers to which the party belongs, as taught by Gai in the combined 
system of Buyukkoc and Christie'565, so that it would ability to allocate network services and 
resources by applying high-level quality of service policies; see Gai col. 5, line 45-55. 
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Regarding claim 26, the combined of Buyukkoc and Christie'656 discloses source 
address screening feature is established for a subscriber to which said party belongs as set forth 
above in claim 25. 

Neither Buyukkoc nor Christie'656 explicitly discloses a group of subscribers. However, 
Gai teaches a policy server (see FIG. 4, policy server 322) comprising the particular policy 
feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device-specific 
filtering entity; see col. 13, line 61 to col. 14, line 5) including a source address screening feature 
for the group of subscribers to which the party belongs (see col. 14, line 1-15, 56 to col. 15, line 
55; applying source addressing policy rule to a group of users (see FIG. 7 A, marking users, 
admin users, executive users, etc.) where a specific user (see FIG. 7A, John Doe) belongs; see 
col. see col. 14, line 10-18). Therefore, it would have been obvious to one having ordinary skill 
in the art at the time the invention was made to provide a source address screening feature for the 
group of subscribers to which the party belongs, as taught by Gai in the combined system of 
Buyukkoc and Christie'656, so that it would ability to allocate network services and resources by 
applying high-level quality of service policies; see Gai col. 5, line 45-55. 

1 1 . Claims 27-29 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Kobayashi (US 5,896,371). 

Regarding claims 27, Buyukkoc discloses a maximum burst size limit feature associated 
with said call (see col. 14, line 15-65; acceptable/maximum load/size before the call are 
blocked). 
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Buyukkoc does not explicitly disclose limiting a burst-size request. However, limiting a 
burst-size request is well known in the art of ATM. In particular, Kobayashi teaches a maximum 
burst size limit feature for limiting a burst-size request associated with said call (see FIG. 6; see 
col. 12, line 55 to col. 13, line 35; a limiting/setting/changing the number of cells transmitted in 
each call). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to limit the number of cells transmitted in each call, as taught by 
Kobayashi in the system of Buyukkoc, so that it would provide a flow control performed 
cooperatively by the network and the terminal equipment and call accepted control is simplified; 
see Kobayashi col. 7, line 46-52; col. 8, line 40-45. 

Regarding claim 28, Kobayashi discloses the number of packets per second allowed to 
be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 to 
col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call to 
ATM network). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the system of Buyukkoc, for the same motivation as 
above in claim 27. 

Regarding claim 29, Kobayashi discloses the number of packets per second allowed to 
be received by said party from said ATM network with respect to said call (see FIG. 6; see col. 
12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to received in 
each call from ATM network). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide the number of packets per second 
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requested to be received, as taught by Kobayashi in the system of Buyukkoc, for the same 
motivation as above in claim 27. 

12. Claim 30 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Smith (US006222823B1). 

Regarding claim 30, Buyukkoc discloses an aggregated bandwidth limit feature for a 
particular network port by said party (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10; 
col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link). 

Buyukkoc does not explicitly disclose for determining a maximum bandwidth allowable 
and authorized for use. However, determining the maximum bandwidth allowable for a particular 
port authorized for use by said party is well known in the art of ATM. In particular, Smith 
teaches determining the maximum bandwidth allowable for a particular port authorized for use 
by said party (see FIG. 1-2; see col. 9, line 5-45, and abstract; determining 
predetermined/allowable/authorized bandwidth for a particular port/connection of end station). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the system of Buyukkoc, so that it 
would cause the system control means to allocate a predetermined bandwidth and balance the 
bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

13. Claims 32-37 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Kilkki (US006041039A). 
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Regarding claims 32-37, Buyukkoc discloses service class as described above in claim 
31 and 58. Buyukkoc further discloses constant bit rate service (CBR) and variable bit rate 
service (VBR) (see col. 1, line 50-60). 

Buyukkoc does not explicitly disclose a real-time VBR service, non-real time VBR, 
unspecified bit-rate (UBR), and available bit-rate (ABR). However, the ATM class of services a 
real-time VBR service, non-real time VBR, unspecified bit-rate (UBR), and available bit-rate 
(ABR) is well known in ATM standard. In particular, Kilkki teaches CBR, VBR, a real-time 
VBR service, non-real time VBR, unspecified bit-rate (UBR), and available bit-rate (ABR) (see 
col. 1, line 54-67). Therefore, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide quality of service class defined by ATM standard, 
as taught by Kilkki in the system of Buyukkoc, so that it would provide a capability to manage 
increases in network load, supporting both real-time and non-real time application, and offering, 
in certain circumstances, a guaranteed level service quality; see Kilkki col. 1, line 44-53, also by 
using the ATM standard services, it will enable the service provider to interoperate between 
multi-vendor networks. 

14. Claim 39,40-43,45,50 and 58 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Buyukkoc in view of Gai (US006 167445 A). 

Regarding claim 39, Buyukkoc discloses a computer-readable medium operable with an 
Asynchronous Transfer Mode (ATM) network node (see FIG. 9, ATM switch 922,924), said 
computer-readable medium carrying a sequence of instructions provided for executing service 
logic which, when executed by a processing entity associated with said ATM network node, 
causes said ATM network node to perform the steps of: 
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upon receiving in said ATM network node a signaling message with respect to a call 
from a party (see FIG. 9, User 902); see FIG. 9, step 810, edge node receive a new call; see col. 
19, line 19-26; also see FIG. 10, step 1005,1010,1015,1020,1025,1030; see col. 20, line 50-67), 
propagating said signaling message to a policy server (see FIG. 7-9, central Routing Status 
Database server, RDS) operably associated with said ATM network node (see FIG. 7, a link 770 
to central RDS server 730, i.e., Signaling Control Point, SCP); and 

upon determining that a policy condition associated with a particular policy feature to be 
invoked is satisfied with respect to said signaling message (see FIG. 8, step 840; see FIG. 10, 
steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; Tables VII-IX; decide how to route 
the call in accordance RSD contents by determining and triggering/invoking a particular/specific 
quality-of-service rule/policy of connection rules/policies for received call's priority of traffic), 
effectuating a treatment for said call based on said particular policy feature (see FIG. 8, step 850, 
860, 870; see FIG. 10, steps 1045,1050,1055; see col. 14, line 1-65; see col. 19, line 35-50; see 
col. 21, line 40-50; setting/establishing the call when load/congestion/priority/bandwidth/routes 
conditions are met/fulfilled). 

Buyukkoc does not explicitly disclose one of a destination screening feature for a group 
of subscribers to which the party belongs or a source address screening feature for the group of 
subscribers. However, Gai teaches a policy server (see FIG. 4, policy server 322) comprising the 
particular policy feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, 
and device-specific filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of 
a destination screening feature for a group of subscribers to which the party belongs or a source 
address screening feature for the group of subscribers (see col. 14, line 1-15, 56 to col. 15, line 
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55; applying source or destination addressing policy rule to a group of users (see FIG. 7 A, 
marking users, admin users, executive users, etc.) where a specific user (see FIG. 7A 3 John Doe) 
belongs; see col. see col. 14, line 10-18). Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to provide one of a destination 
screening feature for a group of subscribers to which the party belongs or a source address 
screening feature for the group of subscribers, as taught by Gai in the system of Buyukkoc, so 
that it would ability to allocate network services and resources by applying high-level quality of 
service policies; see Gai col. 5, line 45-55. 

Regarding claims 40, Buyukkoc discloses establishing a virtual channel connection 
between said party and another party for said call (see col. 20, line 5-45; virtual connection 
between users). 

Regarding claims 41, Buyukkoc discloses denying a virtual channel connection for said 
call (see col. 14, line 44-47; see col. 1, line 66-67; call is block, thereby, blocking the virtual 
connection due to congestion). 

Regarding claim 42, Buyukkoc discloses wherein said signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claims 43 and 45, Buyukkoc discloses wherein said signaling message 
comprises an Add Party or setup message (see FIG. 8, steps 820,830; a message which contains a 
new call requesting for a route is the SETUP/adding party message in ATM signaling/SS7; see 
col. 19, line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, line 19-25). 
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Regarding claim 50, the combined system of Buyukkoc and Gai discloses all limitation 
as set forth above in claim 39. Gai disclose a destination address screening and source address 
screening feature (see col. 14, line 1-15, 56 to col. 15, line 55; applying source and destination 
addressing policy rule; see col. see col. 14, line 10-18). Therefore, it would have been obvious to 
one having ordinary skill in the art at the time the invention was made to provide a destination 
screening feature and a source address screening feature, as taught by Gai in the system of 
Buyukkoc, for the same motivation as set forth above in claim 39. 

Regarding claim 58, Buyukkoc discloses a service class selection feature for specifying 
a service class with respect to a network port used by said party (see col. 10, line 50-55; see col. 
18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of-service for a 
port/link/trunk/circuit used by the call). 

15. Claim 44 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth in claim 39 above, and further in view of Noake (US006751222B1). 

Regarding claim 44, neither Buyukkoc nor Gai explicitly disclose a release message. 
However, a release message is well know in the ATM signaling/SS7 in order to disconnect the 
call. In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc and Gai, so that it would make effective use of a band and the respective 
apparatus by transmitting connection information, and by sending/receiving a release message it 
will notify to stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; 
col. 8, line 19-24. 
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16. Claims 46-48 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai, as set forth in claim 39 above, and further in view of Christie , 656 
(US006690656B1). 

Regarding claim 46, Buyukkoc discloses accessing said ATM network through a 
particular network port associated with said CPE (see FIG. 9, accessing Switch 922 through the 
trunk/port 932; see col. 20, line 1-10). Gai discloses source address screening feature as set forth 

above in claim 39. 

f 

Neither Buyukkoc nor Gai explicitly disclose ensuring that said party is an authorized 
party for accessing the network. 

However, a source address validation for ensuring that said party is an authorized party 
for accessing the network is well known in the art of signaling in order to established the call. In 
particular, Christie'656 teaches a source address validation for ensuring that said party is an 
authorized party for accessing the ATM network (see FIG. 7; see col. 7, line 9-19, 35-45; 
checking/validating caller number in ANI for verification for accessing ATM network). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to validate/verify the caller number to access the ATM network, as taught by 
Christie'656 in the combined system of Buyukkoc and Gai, so that it would can validate the calls 
and generate a billing record; see Christie , 656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 47, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
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logical connection/port between customer and the network). Christie'656 also discloses a 
Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 48, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

17. Claim 49 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth above in claim 39, and further in view of Farris (US006 154445 A). 

Regarding claim 49, Buyukkoc discloses the number of setup messages (see FIG. 8, 
steps 820,830; a message which contains a new call requesting for a route is the SETUP/adding 
party message in ATM signaling/SS7; see col. 19, line 19-31; see col. 20, line 46-52; see col. 20, 
line 39-45; see col. 21, line 19-25). 

Neither Buyukkoc nor Gai explicitly disclose a maximum call attempt rate limit for 
monitoring the number of messages received from said party over a predetermined period of 
time. However, having a maximum call attempt rate limit for monitoring the number of messages 
received from said party over a predetermined period of time is well known in the art of 
signaling and network management. In particular, Farris teaches a maximum call attempt rate 
limit for monitoring the number of setup messages received from said party over a predetermined 
period of time (see col. 14, line 1-12; see col. 11, line 5-56; acceptable/maximum specified rate 
of call attempts for monitoring and determining the number of setup/ISUP messages from calling 
party per time period). Therefore, it would have been obvious to one having ordinary skill in the 
art at the time the invention was made to provide acceptable/maximum specified rate of call 
attempts and monitoring process, as taught by Farris in the combined system of Buyukkoc and 
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Gai, so that it would can detect the predetermined events and/or imminence of predetermined 
events, and then blocking or controlling those events from their incipiency; see Farris col. 14, 
line 1-6. 



1 8. Claim 65 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth above in claim 39, and further in view of Basso (US006633539B1). 

Regarding claim 65, Buyukkoc discloses a policy feature comprise a maximum call 
limit feature for specifying the total number of calls allowed concurrently with respect to a 
network port used by said party (see col. 14, line 10 to col. 15, line 50; see FIG. 9, trunk/port 
932; see col. 20, line 1-10; acceptable/allowable total number of calls threshold/limit for a 
trunk/port). 

Neither Buyukkoc nor Gai explicitly disclose concurrent. However, ATM network 
having a maximum concurrent call limit/threshed for call admission control (CAC) is well 
known in the art. In particular, Basso teaches a maximum concurrent call limit feature (see col. 4, 
line 25-35; maximum allowed/limit number of concurrent connection/call). Therefore, it would 
have been obvious to one having ordinary skill in the art at the time the invention was made to 
provide maximum concurrent connection, as taught by Basso in the combined system of 
Buyukkoc and Gai, so that it would control concurrent connections/calls to provide efficient 
protection against signaling congestion; see Basso col. 2, line 35-45. 

19. Claims 54-56 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai, as set forth in claim 39 above, and further in view of Kobayashi (US 5,896,371). 
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Regarding claim 54, Buyukkoc discloses a maximum burst size limit feature associated 
with said call (see col. 14, line 15-65; acceptable/maximum load/size before the call are 
blocked). 

Neither Buyukkoc nor Gai explicitly disclose limiting a burst-size request. However, 
limiting a burst-size request is well known in the art of ATM. In particular, Kobayashi teaches a 
maximum burst size limit feature for limiting a burst-size request associated with said call (see 
FIG. 6; see col. 12, line 55 to col. 13, line 35; a limiting/setting/changing the number of cells 
transmitted in each call). Therefore, it would have been obvious to one having ordinary skill in 
the art at the time the invention was made to limit the number of cells transmitted in each call, as 
taught by Kobayashi in the combined system of Buyukkoc and Gai, so that it would provide a 
flow control performed cooperatively by the network and the terminal equipment and call 
accepted control is simplified; see Kobayashi col. 7, line 46-52; col. 8, line 40-45. 

Regarding claim 55, Kobayashi discloses the number of packets per second allowed to 
be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 to 
col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call to 
ATM network). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the combined system of Buyukkoc and Gai, for the same 
motivation as above in claim 54. 

Regarding claim 56, Kobayashi discloses the number of packets per second allowed to 
be received by said party from said ATM network with respect to said call (see FIG. 6; see col. 
12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to received in 
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each call from ATM network). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide the number of packets per second 
requested to be received, as taught by Kobayashi in the combined system of Buyukkoc and Gai, 
for the same motivation as above in claim 54. 

20. Claim 57 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth in claim 39, and further in view of Smith (US006222823B1). 

Regarding claim 57, Buyukkoc discloses an aggregated bandwidth limit feature for a 
particular network port by said party (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10; 
col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link). 

Neither Buyukkoc nor Gai explicitly disclose for determining a maximum bandwidth 
allowable and authorized for use. However, determining the maximum bandwidth allowable for 
a particular port authorized for use by said party is well known in the art of ATM. In particular, 
Smith teaches determining the maximum bandwidth allowable for a particular port authorized for 
use by said party (see FIG. 1-2; see col. 9, line 5-45, and abstract; determining 
predetermined/allowable/authorized bandwidth for a particular port/connection of end station). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the combined system of 
Buyukkoc and Gai, so that it would cause the system control means to allocate a predetermined 
bandwidth and balance the bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 
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21. Claims 59-64 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai 5 as set forth in claim 39, and further in view of Kilkki (US006041039A). 

Regarding claims 59-64, Buyukkoc discloses service class as described above in claim 
31 and 58. Buyukkoc further discloses constant bit rate service (CBR) and variable bit rate 
service (VBR) (see col. 1, line 50-60). 

Neither Buyukkoc nor Gai explicitly disclose a real-time VBR service, non-real time 
VBR, unspecified bit-rate (UBR), and available bit-rate (ABR). However, the ATM class of 
services a real-time VBR service, non-real time VBR, unspecificed bit-rate (UBR), and available 
bit-rate (ABR) is well known in ATM standard. In particular, Kilkki teaches CBR, VBR, a real- 
time VBR service, non-real time VBR, unspecified bit-rate (UBR), and available bit-rate (ABR) 
(see col. 1, line 54-67). Therefore, it would have been obvious to one having ordinary skill in the 
art at the time the invention was made to provide quality of service class defined by ATM 
standard, as taught by Kilkki in the combined system of Buyukkoc and Gai, so that it would 
provide a capability to manage increases in network load, supporting both real-time and non-real 
time application, and offering, in certain circumstances, a guaranteed level service quality; see 
Kilkki col. 1, line 44-53, also by using the ATM standard services, it will enable the service 
provider to interoperate between multi- vendor networks. 

Response to Arguments 

22. Applicant's arguments with respect to claims 1-65 have been considered but are moot in 
view of the new ground(s) of rejection. 
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Regarding claims 1-50,54-65, the applicant argued that, "...Buyukkoc does not 
disclose or suggest propagation a signaling message to a policy server, where the policy server 
includes at least one policy profile having a plurality of policy features, and where each policy 
profile of the at least one policy profile is associated with a subscriber... " in page 24, 25, 31-34. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Buyukkoc discloses propagating said signaling message (see FIG. 8, Step 820; see FIG, 
10, step 1030; sends setup for a new call to RSD) to a policy server (see FIG. 7, a link 770 to 
central RDS server 730, i.e., Signaling Control Point, SCP), said policy server including at 
least one policy profile having a plurality of policy features (see col. 14, line 9 to col. 15, line 
50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD contents 
consists connection rules/policy such as connectively information, threshold, quality of 
service, capacity, and/or status of loading/congestion), and where each policy profile of the at 
least one policy profile being associated with a subscriber (see col. 14, line 35-64; a quality of 
service rule/policy is one of the rule/policy associated with a call, where a call is associated 
with a user/subscriber). 

Regarding claims 39-50,54-65, the applicant argued that, "...Buyukkoc does not 
disclose or suggest upon determining that a policy condition associated with a particular policy 
feature to be invoked is satisfied with respect to said signaling message, effectuating a treatment 
for said call based on said particular policy feature, the particular policy feature including at least 
one of a destination address screening feature for a group of subscribers to which the party 
belongs or a source address screening feature for the group of subscribers... " in page 30-34. 
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In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Buyukkoc discloses upon determining that a policy condition associated with a particular 
policy feature to be invoked is satisfied with respect to said signaling message (see FIG. 8, step 
840; see FIG. 10, steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; Tables VIHX; 
decide how to route the call in accordance RSD contents by determining and 
triggering/invoking a particular/specific quality-of-service rule/policy of connection 
rules/policies for received call's priority of traffic), effectuating a treatment for said call based 
on said particular policy feature (see FIG. 8, step 850, 860, 870; see FIG. 10, steps 
1045,1050,1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, line 40-50; 
setting/establishing the call when load/congestion/priority/bandwidth/routes conditions are 
met/fulfilled). Gai discloses a policy server (see FIG. 4, policy server 322) comprising the 
particular policy feature (see FIG. 4, Policy Rule generation engine 414, policy translator 
410, and device-specific filtering entity; see col. 13, line 61 to col. 14, line 5) including at least 
one of a destination screening feature for a group of subscribers to which the party belongs or a 
source address screening feature for the group of subscribers (see col. 14, line 1-15, 56 to col. 
15, line 55; applying source or destination addressing policy rule to a group of users (see 
FIG. 7A, marking users, admin users, executive users, etc.) where a specific user (see FIG. 
7A, John Doe) belongs; see col. see col. 14, line 10-18). 

Thus, the combined system of Buyukkoc and Gai discloses argued limitation as set forth 
in rejection above. 

The following responses are generally applicable to all applicant arguments. 



Application/Control Number: 09/766,943 



Page 29 



Art Unit: 2616 

I. Examiner assert the applicant's "policy server" as Buyukkoc's "RSD" as set forth 
above for the following reasons: 

Applicant disclosure (summary of invention) discloses , page 7, lies 11-14, 17-18 as 
follows: 

"the present invention is related to an intelligent policy server system and method for 
providing multiple service policy service policy feature or option and for managing bandwidth 
usage in the an ATM network. . . which policy server is also referred as a Multi-Service Control 
Point or MSCP..." 

As recited in above rejection, Buyukkoc discloses in col. 1 1, line 5-15, as follows: 

"The RSD may be used in conjunction with a number of other innovations. For example, 
the RSD may be used in conjunction with a service control point (SCP) of an Intelligent 
network. An SCP determines an appropriate destination for a call having more than one possible 
destination, such as a call to the 800 number of a large customer that may be routed to one of a 
number of regional service centers, based on factors such as the availability of representatives in 
the various service centers. The RSD may be accessed after an SCP or at the same time as 
an SCP, and the same server may provide RSD and SCP functionality." (Emphasis added) 

Thus, it is clear that Buyukkoc's RSD is the applicant "policy server", 

II) Examiner asserts the applicant's "policy profile having a plurality of policy 

features" as RSD's "connection rules/policy such as connectively information, threshold, 

quality of service, capacity, and/or status of loading/congestion". 

Applicant disclosure discloses, page 7, lies 1 1-14, 19-21; page 7, line 1-7 as follows: 

"the present invention is related to an intelligent policy server system and method for 
providing multiple service policy service policy feature or option and for managing bandwidth 
usage in the an ATM network. . .A return message from the policy server determines whether 
a call connection can be made through the network or not... Depending on the triggers 
associated with a signaling message received in the edge switch, a particular feature is invoked 
and executed by the policy server... burst-size limit, class-of-service provisioning, maximum 
concurrent call connections in progress, bandwidth control... are provided as exemplary 
features implemented in a presently preferred exemplary embodiment of the present invention.." 
(Emphasis added) 
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As recited in above rejection, Buyukkoc discloses as follows: 

"For each (source, destination) pair in the network, the RSD contains some or all of the 
following information. Depending on the needs and size of the network, a "destination" could be 
a terminating switch or it could be a trunk group or virtual path. Connectivity information 
regarding the set of routes that can be used to interconnect the source and destination. 
Information about alternate routes. Information on the capacity of each route in the network. 
Status of all of the routes in the network. Status could be in the form of free or available 
capacity or utilization on each link, or could be a status indicator such as "lightly loaded", 
"heavily loaded", "extreme congestion". The data needed to manage routing features 
responsible for distributing load to multiple physical destinations based on some rule or 
logic. 

Tables VII-IX show a sample RSD for the network of FIGS. 1-5. The Tables show 
information for only a limited number of routes, whereas a real RSD would have more complete 
information. In particular, if there are k routes between each pair of edge nodes and n edge 
nodes in the network, the total number of rows in the Route Status Table (Table IX) is kn(n-l)/2. 
The .alpha.-link, .beta.-link, source, destination, and VPI numbers of Tables VII-IX refer to the 
reference numbers of FIGS. 1-5. 

Table VII contains the current usage of each .alpha.-link. Table VII also contains 
two congestion thresholds for each link, which define three congestion status ranges — 
referred to as "green," "yellow," and "red," in increasing order of congestion. A status of 
"green" may mean that the route has plenty of capacity left and that new calls can be routed there 
with no difficulty. A status of "yellow" may mean that the link is beginning to get congested and 
that alternate routes should be used if available. A status of "red" may mean to avoid using the 
route if at all possible. For example, if a call arrives and all its possible paths are "red," the call 
may be blocked, depending upon its priority. For example, .alpha.-link 214 has a "green" 
congestion status when the usage is not greater than 1 .4 Gbps, a "yellow" congestion status when 
the usage is greater than 1.4 Gbps and not greater than 1.8 Gbps, and a "red" congestion status 
when the usage is greater than 1.8 Gbps. The current usage of .alpha.-link 214 is 1.312 Gbps, so 
the congestion status is "green." The current usage and congestion status of each link are 
periodically updated. It may be desirable to define different congestion thresholds for different 
links, due to factors such as different capacities and different expected usage volumes. In 
addition, it is preferable to incorporate a safety margin of additional capacity into the thresholds, 
because there is some potential for the information in the RSD to be slightly inaccurate or 
outdated. While Table VII only shows 2 congestion thresholds that define 3 congestion 
status for each link, many more thresholds and congestion status may be defined to allow 
for load balancing, overload control, and priorities for different quality-of-service traffic. 

Table VIII gives the status of the .beta.-links in the network. The information in Table 
VIII is similar to that in Table VII, but applies to .beta.-links instead of .alpha.-links. 

Table IX gives the Route Status Table. The .alpha.-links and .beta.-links associated 
with each route are identified, and the congestion status for each route is maintained. The 
congestion status can be periodically updated from the individual link congestion status 
information in Tables VII and VIII. There are many possible methods for defining Route Status 
based on Link Status. Route Status could be defined as equal to the status on the most congested 
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link in the route, or as an average of the congestion status values for each link in the route. Many 
other definitions are possible, and the present invention is not intended to be limited to any 
particular set of definitions. The Route Status values in Table IX are based on using the status of 
most congested link on the route from Tables VII and VIII..." see col. 9, line 50 (Emphasis 
added). 

"For example, a particular RRSDS 740 may receive information from several edge nodes 
720 regarding the amount of bandwidth that each of the edge nodes uses on a particular .beta.- 
link 715. RRSDS 740 may aggregate this information into a single piece of information that 
represents the total bandwidth used on the particular .beta.-link by those edge nodes 720 that are 
connected to the particular RRSDS 740. CRSDS 730 receives information from each RRSDS 
740, and uses this information to compute the total bandwidth usage on each .alpha.-link and 
each .beta.-link..." see col. 13, line 36-46. 



In addition, Buyukkoc also discloses 

"A new call arrives at originating switch 270, which determines that the call is destined 
for switch 220. The (origination, destination) information is passed to the RSD, which contains 
the information shown in Tables VII-IX. If there are different possible bandwidth 
requirements for different types of calls, the bandwidth requirement is preferably also 
passed to the RSD. The RSD uses the information in Table IX to determine that the best 
route from switch 220 to switch 270 is B2, with a congestion status of "green." The RSD 
then increments the current usage and congestion status entries for .alpha.-links 224 and 
214 in Table VII and .beta.-links 118 and 116 in Table VIII. Several techniques could be 
used to update the Status Field in Table IX. For example, it could be updated periodically, or 
upon a change in a congestion status. When the call ends, or does not make a successful 
connection, switch 220 and/or switch 270 sends another message to the RSD, and the RSD 
decrements the current usage on the applicable .alpha.-links and .beta.-links..." see col. 17, line 
30-49. 

"Class-of-service on an end-to-end basis may be implemented using the RSD. Using 
Method 8, for example, the originating edge node passes a class-of-service indicator to the RSD 
in addition to the origination and destination information for the call. The RSD uses the Route 
Status in Table IX to give priority to the more important calls. For example, if the Route 
Status is Green, any call can use the route. If the status is Yellow, only high priority calls can 
use the route, and if the status is Red, only the most critical calls can use the route. This example 
may be generalized to additional congestion status levels. Alternatively, the RSD can route only 
a fraction of calls of lower priority on more congested routes. For example, if the Route Status is 
yellow, then a rule might be that 25% of low priority calls and all of the high priority calls can 
use the route..." see col. 18, line 25-40. 



Thus, it clear that the applicant exemplary policy/rule/plan features of a policy profile 
such as "burst-size limit, class-of-service provisioning, maximum concurrent call 
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connections in progress, bandwidth control" clearly disclosed by Buyukkoc's SCP 
policy/rule/administration/guideline/plan/procedure/scheme having plurality of features such as 
bandwidth control/management, class-of-service, and/or loading/congestion of network (i.e. 
concurrent calls connection in progress) as defined in detailed by tables VII-IX. 

III. Examiner asserts applicant's "at least one policy profile" as Buyukkoc's "quality of 
service priority of a request call". 

Buyukkoc discloses: 

"Table VII contains the current usage of each .alpha.-link. Table VII also contains two 
congestion thresholds for each link, which define three congestion status ranges -referred to as 
"green, " "yellow," and "red," in increasing order of congestion. A status of "green" may mean 
that the route has plenty of capacity left and that new calls can be routed there with no difficulty. 
A status of "yellow" may mean that the link is beginning to get congested and that alternate 
routes should be used if available. A status of "red" may mean to avoid using the route if at all 
possible. For example, if a call arrives and all its possible paths are "red," the call may be 
blocked, depending upon its priority " in col. 14, line 35-46. 

Thus, it is also clear that applicant "one policy profile" is disclosed by Buyukkoc as 
"quality of service or priority of a new request call" where a new call has a priority associated 
with different quality of service, and RCD invokes "priority or quality-of-service" rule/policy 
such as "green", "yellow" or "red" for establishing a call based on its request. 

Moreover, it also clear that Buyukkoc discloses determining if a particular policy feature 
is to be invoked (i.e. bandwidth control/management, class-of-service, and/or loading/congestion 
of network (i.e. concurrent calls connection in progress) in a policy server/RSD, based at least in 
part on said signaling/request message, and if so, determining in accordance with a 
rule/policy/guide line of bandwidth control/management, class-of-service and/or 
loading/congestion of network (i.e. concurrent calls connection in progress) for request/signaling 
message and as set forth above rejection. 
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Conclusion 

23. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ian N. Moore whose telephone number is 571-272-3085. The 
examiner can normally be reached on 9:00 AM- 6:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Doris To can be reached on 571-272-7629. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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